The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: faisalahammad <faisalahammad@git.wordpress.org>
Co-authored-by: marceltannich <mardroid@git.wordpress.org>
Co-authored-by: davidperezgar <davidperez@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Tested during WCEU 2026 Contributor Day.

Manual testing:

• Tested the functionality introduced in this PR (via the 2 test plugins and some others I had available)
• Behavior matched expectations.

Automated checks:

• ✅ composer lint
• ✅ composer phpstan
• ✅ composer phpmd
• ✅ PHPUnit (477 tests, 1352 assertions)

Result:

• All checks passed.
• No issues found during testing.

Note:

• PHPUnit reported a phpunit.xml validation warning (filter element not expected), but the full test suite completed successfully and all tests passed.

Thanks for working on this. I reviewed the PR and also used ChatGPT to help compare it against our internal trialware scanner. The conclusion is that this is a good start, but I don’t think it satisfies the issue yet.

The main gap is that the issue asks for an AI-assisted candidate workflow, not a direct regex-to-error check.

Right now this PR:

• scans PHP/JS files for a few trialware-like regex patterns;
• immediately reports every match as an error;
• does not distinguish candidates from confirmed violations;
• does not run an AI review step;
• does not hide/discard false positives;
• does not include coverage for acceptable cases like external services, separate premium plugins, or harmless license/update wording.

The internal scanner this is based on works differently:

• it first detects broad candidate patterns such as license keys, activation codes, free trial wording, lite/free version limits, “to unlock”, “limit reached”, plan limits, etc.;
• it sends those candidates to an AI review prompt;
• the AI is asked to confirm whether bundled plugin functionality is actually restricted;
• AI-confirmed cases become actionable issues;
• AI-discarded cases are removed from the final output.

That distinction is important because trialware detection has a high false-positive risk. For example, a plugin may mention a premium version, use an external service API key, or include license/update-related wording without actually locking functionality bundled in the WordPress.org plugin. Those should not become final blocking errors.

To move this closer to the requested behavior, I think this needs:

1. Candidate result codes, e.g. trialware_locked_feature_candidate.
2. Confirmed result codes, e.g. trialware_locked_feature_detected.
3. An AI prompt/check step that decides whether the candidate is a real locked built-in feature.
4. Logic to suppress AI-discarded candidates from final results.
5. Broader candidate patterns matching the internal scanner, including UI/readme/string-level restriction wording.
6. Tests for both confirmed trialware and false-positive cases.

So I would not consider this complete yet. It is a useful skeleton for the static candidate detection piece, but it is missing the key AI confirmation/discard workflow from the issue acceptance criteria.

Thanks for the detailed review. Good catch on the missing AI confirm/discard step.

Looked into how plugin-check already handles this for other checks. Turns out there's a generic mechanism already built for exactly this: AI_Analyzer::get_ai_prompt_map() maps check-code prefixes to a prompt file, and Abstract_Check_Runner::run() runs an AI pass after all checks finish (via --ai flag), tagging each candidate as confirmed or false-positive. EscapeOutput, NonceVerification, DirectDatabaseQuery, Obfuscation, SettingSanitization, and PluginUpdater all use this same pass today — none of them call AI inside the check class itself.

So instead of building a second, bespoke AI workflow just for trialware, I wired the trialware_*_candidate codes into that existing pass:

• Added trialware_ to get_ai_prompt_map().
• Added prompts/ai-review-trialware.md, which explicitly tells the AI to treat external service API keys, a separate premium plugin/product, and harmless license/update-checker wording as false positives, not confirmed gates.
• Broadened the regex patterns to cover your examples: activation codes, "free trial ended/expired", "to unlock ... feature", "limit reached", lite/free-version gating.
• Added 3 false-positive-shaped functions to the clean test fixture (external API key, separate premium plugin mention, EDD-style license) — still 0 errors, so the regex layer itself doesn't over-match before AI ever runs.

This keeps trialware consistent with how every other AI-reviewed check works, and the candidate/confirm/discard behavior you asked for comes from the existing runner pass rather than new plumbing. Full details in the updated PR description. Let me know if you'd rather see dedicated _detected result codes instead of relying on the existing ai_stats/ai_analysis output — happy to adjust if that's a hard requirement.